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: / REVIEW OF THE IHS ARCHITECTURAL FUNCTION IN THE AGENCY 


The Office of the IHSA was established in January 1981 in 
accordance with the directions of the EXCOM, based on its review of 
the findings and recommendations of the Information Handling Task 
Force. The office was established to plan, coordinate, guide, and 
approve the overall design of the Agency's information handling 
systems (IHS). The objective is to achieve an integrated, non- 
redundant total Agency IHS architecture that is responsive to the 
totality of user needs, while maximizing the payoff for the 
investment. The IHSA also is to serve as the prinicipal focal point 
for community contact and top-level information concerning the status 
of the Agency's IHSs. The office function is one of top-level 
management and planning, and does not involve development of system 
requirements or system implementation. 


FOCUS OF THIS PRESENTATION 


The IHSA has been assigned the responsibility of making an annual 
report to the EXCOM on the status of IHSs in the Agency. In this 
first report, the focus is on the key problems and proposed approach 
of the office of the IHSA in dealing with those problems. 


In the memorandum reporting the conclusion of the EXCOM, it was 
stated that "The Committee agreed to adopt the proposed mission and 
function statements for the time being and review them for possible 
revision after the ‘architect’ has been in operation long enough to 
evaluate them." The office has now been organized, the staff 
selected, and has begun operation on the basis of the proposed mission 
and function statements. Principally, these are the mission and 
function statement of the Architect of Information Services that was 
prepared by the DDA in response to EXCOM guidance. It is now 
appropriate to review that mission and function guidance and change 
and ratify it as appropriate, in accordance with EXCOM findings. 
Clear guidance and a statement of missions and functions, from the 
EXCOM to the IHSA, is needed to direct the office and establish its 
acknowledged role in the Agency community. 


Since discussing the entire package of findings and 
recommendations would be an excessively long and generally 
unproductive undertaking, this report focuses on the key problems and 
the recommended approach and authorities of the IHSA to deal with 
them. The concern is with key problems found by the IHSA, but for 
which no recommendations were made, and with other issues found by the 
IHSA to be fundamental to the execution of the general IHSA 
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responsibility. Issues and approaches which are felt to be non- 
controversial are assumed to be accepted and have been omitted from 
discussion for the sake of brevity. 


THE KEY PROBLEMS AND THEIR RESOLUTION 


In the following paragraphs, the key problems in accordance with 
the above stated criteria, and as perceived by the IHSA are presented. 


1. Approval of Systems 
I believe the current top-level management involvement for IHSs to 


be primarily budgeting. The Directorates operate on the philosophy 
that, once the money is available, spending it on the designated 


‘subject is at the discretion of that Directorate. In other words, it 


is a local-option environment. 


I do not believe that the function of the IHSA has any significant 
value unless top-level management is instituted with respect to IHSs 
and this office plays a key role in that management. That is the only 
way IHSs cdn achieve interoperability as part of a larger 
architecture, precious resources can be used to develop and operate 
systems in an efficient and effective manner, and the planning and 
environment needed to support sysems development can be created, 


The extant guidance on the approvals is scant and is contained in 
a DDCI memorandum of 26 July 1978 (DCI 78-8710/16). It specifies that 
all projects with an annual investment cost greater than $250,000 will 
be reviewed annually by the EAG (predecessor to the EXCOM). It does 
not specify any initial required documentation, such as functional 
requirements, development plan, or costs. There is also overlapping 
guidance with respect to ODP approval of ADP systems and ADPE in HR 
[_jof 13 August 1975, which defines ODP's charter. The latter 
specifies approval authorities which are redundant to those now 
assigned to the IHSA in[ of 16 March 1981. . Such approval 
redundancy needs to be resolved, since such a layeréd, duplicative 
process is not helpful. ge 


Agency discretion with respect to the formulation of its top 
management process has recently been somewhat limited by two recent 
actions. Section 3506 of the Paperwork Reduction Act of 1980 
specifies that each agency shall appoint a senior official, reporting 
to the agency head, to carry out agency responsibilities under the 
act. These include review, planning, budgeting, and training with 
respect to IHSs. Even if the Agency receives a general waiver from 
the terms of this act because its systems relate to such activities as 
the collection of foreign intelligence, the intent of Congress that 
there be a single, designated, agency management and control point for 
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IHSs is clear. 


The second action derives from the Agency's request, along with 
those of several other agencies, for a general delégation of authority 
for waivers from the NBS Federal Information Processing Standards 
(FIPS), managed for the Governnment by the Department of Commerce. In 
its letter of 6 April 1981, the Commerce has responded that it is now 
coordinating action "to amend the FIPS to delegate to heads of 
agencies the authority to approve waivers." It is the view of NBS 
that the letter represents a statement of clear intention to delegate 
the waivér authority by DOC, subject to approval by OMB and possibly 
Congréss, The delegation would be made in a formal instruction that 
Clearly specifies the acceptable conditions for such waivers. As in 
the Paperwork. Reduction Act, a senior individual reporting directly to 
top-Agency management would have to be delegated the waiver management 
responsibility. This individual should not also be responsible for 
systems implementation, but would review the waiver requests of 
parties responsible for such systems implementation. 


We thus have three factors pointing towards the necessity of 
assigning the IHSA approval authority of IHSs: the basic need for 
top-level, centralized management of IHSs; the agency responsibilities 
under the Paperwork Reductions Act; and the DOC delegation of waiver 
authority with respect to the FIPS. Even if the EXCOM had not 
recommended such authority, it would seem to be mandatory at this 
point if the Agency's top-management responsibilities are to be met. 


2. Accreditation of System Requirements 


The source of the problem is probably the old aphorism, "The user 
is responsible for requirements." While this functional assignment 
sounds logical, it is a simplistic concept that can lead to real 
problems if interpreted as the delegation of an exclusive prerogative 
to the user. Some of the principal sources of such problems are: 

o Lack of a reconciliation of the user's requirements — 
with the implementation environment; . 
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o Inadequate attention to adjunct user requirements; 
and 


o Lack of a consolidation and validation mechanism 
for requirements derived from a community of users. 


The lack of reconciliation involves an interactive process between 
the user and developer. The system requirements should evolve from 
the functional requirements as the consequence of an interplay between 
the techniques and mechanisms of their implementation and the 
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restructuring of user organizations or Sperations in conjunction with 
the;new system. One of the worst mistakes that can be made is simply 
to automate current manual procedures; the result is usually a system 
several times the size and cost as would satisfy the need. The 
implications of such a direct transformation approach are not always 
well understood by user organizations. 


With reference to adjunct requirements, there is an increasing 
functional complexity of Agency systems due to the increasing 
involvement of adjunct users. Instead of a system like PERSIGN, which 
is a personnel management system with a homogenous set of users, we 
are now developing systems like LIMS, a logistics system with many 
adjunct user organizations. The problem of the definition of the 
‘requirements for such a system can be difficult, particularly when an 
Ioc gate and ares constraints force compromises. 


Lastiy, there is the problem of requirements for general services 
systems. The requirements for these systems drive their cost, 
availability, and acceptance just as they do for any other. The 
problem is the establishment of an acceptable, but not excessive, set 
of requirements. The Agency history has been that the developer sets 
the requirements for such systems, based on user surveys and/or 
projections of historical use data. A distinct hazard with this 
process once it has begun is the natural migration of management 
concern to the technical issues of implementation, to the detriment of 
user interest. 


All of these examples reflect a strong need for accreditation of a 
new systems functional requirements. For complex systems, this can 
only be done at an Agency-wide level, since the problem is an 
ecumencial one. It also requires concentrated top-level attention, 
Since the problems are complex. They cannot be successfully dealt 
with in an EXCOM-type project review unless the key issues and 
tradeoffs have already been identified and analyzed. 


3. Lack of Systems Development Guidance and Training 


The Agency is in an almost unique position among\major Government 
agencies in providing no Agency-wide guidance for the development of 
IHSs. Some formal guidance has beén developed in some groups, and 
there is a lot of high-powered expertise, but little of it has been 
formalized, even at the group level. 


‘: 
< 


This lack of guidance is a major problem because there is a 
tremendous variation in the way developments are done among groups in 
the Agency. Compounding the problem is the fact that because of the 
constrained budget situation, experience in the development of large 
or moderate-sized systems is quite limited. While Agency experience 
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‘tends to be in terms of things built with just a few people, we are 
now looking at the catch-up need to develop many moderate and large- 

, ‘Sized systems. Our people need guidance, training, and standards to 
execute this new phase with any degree of success, 


By itself, guidance will be of very limited value; it needs to be 
supplemented by an effective training program. I believe that a 
significant portion of the Agency's IHSs professionals have been 


involving $100M in acquisition cost is involved; since they think they 
are dealing with the development of smaller systems, they think they 
~do'not need formal procedures. 


“We need to develop a common culture, a common understanding. To 
do that we need to put a major emphasis on training. To do the job it 
has to do, that training has to be centralized. The engineer 
acquiring Software for MERCURY in OC should have the same approach and 
contractor procedural and documentation requirements as that acquiring 
the CAMS~II in ODP, as that acquiring CRAFT in IMS. [If they do not 
the problem of making these systems interoperate is made immeasurably 
more difficult. 


Theré are two types of training required:. skills and 
disciplinary. We have a comprehensive course structure for the 
former, generally, dispensed throughout the Agency. ODP now does 
Agency—wide skills training relevant to the use of ODP systems. 
Because this program was established as component training, however, 
‘there are substantial waiting periods to get into most courses. The 
waiting period for the Basic VM course, for example, is about six 
Months, 


The Agency handles disciplinary training on an ad hoc basis. 
Sometimes Agency personnel teach a course under a university's 
auspices, and frequently staff members attend the nimerous three or 
five-day short courses Sponsored by professional societies, 
universities or other groups. But we do not present such courses 
internally in the manner that the. Information Services's Program in 
OT&E offer courses in analytic tools to the intelligence community. 
Our ability to develop a common IHS culture, in my judgement, requires 
that we offer internally, from a centralized source, a full curriculum 
of skills and disciplinary training. 


OT&E was recently tasked by the DDA at the IHSA's request to 
perform a study of Agency training requirements for THSs. A report of 
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the study is appended (Appendix B). Precise results were not 
available because components, for the most part, had not begun to 
think specifically about and plan for the problem, Basically, 
‘however, it shows that a very substantial jump in the Agency-wide IHS 
training requirements is imminent. This is compounded by the fact - 
that we are not even keeping up with our current training requirement. 


To bound the problem, OT&E estimated the resources required if all 
the training, including component-unique training which is normally 
done by the components, were done centrally. They found that their 
resources in terms of people, space, and equipment dedicated to the 
purpose, would approximately have to triple. This estimate also was 
based on the assumption of totally scheduled training, that is no ad 
hoc training. Actually there is ad hoc training, and the more 
distributed it is, the higher the proportion of the total it 
represents. Ad hoc training significantly decreases the efficiency of 
training, These would also be component-unique training done by the 
components, again decreasing efficiency. 


Very clearly, if this IHS training requirement is not centrally 
managed, there will be a substantial growth in component training. 
Each of tHe Directorates would shortly have IHS training centers and 
dedicated resources several times that currently existing in OT&E. I 
would estimate that such a distributed training approach would be no 
better than about half as efficient as a centralized one. 


A greater concern, however, is the development of a common IHS 
culture. Distributed IHS training would destroy any possibility of 
developing such a common IHS culture within the Agency. Developing a 
training program that will meet all the needs of the Agency will 
require top-level guidance and support. 


The other part of the environment problem is the development ef 
standards. We need standards in three areas relative to IHS ~  _ 
development: . 7 be 

> \ 


o Management procedures and development processes standards 
o Interface control standards 


o Data item specifications (e.g., per CDRL) 
Examples of documents in each category. exist, some of them excellent. 
But these are not standards or guidances even at the Directorate 
level. A moderate or large-sized systems development can readily 
require the adherence to or production of 20 different documents. For 
-the project personnel to figure all that out de_novo is an 
unreasonable requirement, and it certainly is not going to produce a 
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homogenous environment. It is, however, our current situation. The 
ability of systems to interoperate ina unified architecture is 
probably as much a function of how they are built as what interface 
requirements are levied upon them. 


In order to have a single set of standards and have them for the 
entire Agency we need centralized development and promulgation of such 
standards. 


4, Robustness and "User Friendly” Systems 


. Over the past five to ten years, I believe the impact of the 
tightly constrained Agency budgets has been to force the IHSs into an 
increasingly cost-effective posture. Unfortunately, this increased 
cost-effectiveness has been achieved at the expense of robustness. As 
a consequence, we now have highly fragile data processing and 
communications systems architectures. User availability of the 
central systems is significantly below expectations, point failures 
tend to cascade through the systems, and the ability to respond to 
contingencies is not adequate for an Agency that is to support 
contingency and wartime operations. 


Robustness, like security, costs money and contributes little, if 
anything, to performance. Working our way out of the fragility corner 
requires reordered priorities and an advocate--the user's concern 
tends to be with solving his immediate problems and the supplier of 
the service with meeting the user's needs. Robustness is an 
architectural concern and one that needs concentrated attention in the 
near term future. 


As our user base expands rapidly, we need to develop "user 
friendly systems." We have made a very substantial investment in 
developing our central systems and have now, as a consequence, some 
unique and remarkable capabilities. We also have a system that 
requires high degree of expertise to use in many areas. Expertise, 
unfortunately, can also be correlated directly with the amount of 
training required. % 5 


oY. : 

User friendly systems involve both the simpler interfaces, as seen 
by users on their visual display terminals (VDT), and simpler 
facilities. This greater use of menu-driven functionalities is needed 
so that users will not have to become experts in the instruction sets, 
operational structure and syllogism of particular functionalities, 
such aS a data base management system. We also need simple 
functionalities for the facile implementation of small-scale 
applications. Users become frustrated when they have to learn how to 
use complex functionalities in order to perform a simple task. 
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Development of "user friendly" systems requires priority and 
investment. The user payoff is diffuse and hard to measure. As a 
consequence, I believe achieving it requires an advocate to guide and 
support it. 


5. Scientific Programming 


| Scientific programming to support intelligence analysis is a 

particular problem area at the present time. The Agency used to have 

a group dedicated to scientific programming, but there were a series 

of reorganization moves involving it, and gradually, its members 

either left the Agency or joined user groups. We no longer have a 

scientific .Progeanm ing group and I believe this to be a major concern. 
yh : 

' We Have some. highly skilled indiviauare in analytic user 
organizations, but not many. We are plagued by the problem that such 
individuals can command high salaries in the commercial market place 
‘where their promotability is not hampered by a need to move into 
management , as it tends to be here. Here their careers cap out fairly 
quickly if they are in an intelligence analysis career path, and the 
only option they have to continue to advance their career is to leave. 


_. Because we have lost the scientific programming group and cannot 
retain highly skilled scientific programmers in user organizations, 
- the Agency now primarily depends on contractors for scientific 
programming support. Using contractors is certainly not a problem, 
but depending on them is. I understand the impact on our program was 
severe when one contractor recently had to be terminated because of 
security violations. When we lack a solid in-house scientific 
programming resource base, we are in a very tenuous position. In 
addition, I believe the demand for scientific programming is likely to 
be rapidly increasing. It is typically what happens next after 
analysts learn how to operate on a terminal and get word Processing. 
and analyst file functions under their belts. % 


Rebuilding a scientific programming sapapitieg as going to take 
top-management attention. I believe that we need to develop a 
"critical mass" of such people in a coherent organization with a clear 
career path. They need to see SIS-level scientific programmers in 
leadership positions and an appropriate GS grade-level profile. 
Obtaining these conditions implies organizational changes in both 
implementing and user organizations to achieve an environment 
attractive to such highly skilled people. Only with the Agency career 
attractiveness could we afford to hire and make the substantial 
continuing education investments that such personnel require. 


6. Efficient Utilization of the IHS Resources 
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My perception is that there has been a tremendous shift in 
attitude within the Agency regarding IHSs just within the past several 
years. A few years ago, most professionals with analytic or 
operational responsibilities seemed to view IHSs as an arcane 
technology that was the province of highly trained specialists. Today 
I believe the current perception to be that an ability to utilize IHSs 
is important to all professionals if they are to develop and apply 
their skills at a level of effectiveness reflecting the contemporary 
environment. . 


This very rapid growth of interest has produced an explosion of 
‘demand. Very clearly, our IHS user community is going to expand by an 
order of magnitude in just a few years. Managing that explosion of 
demand to provide efficient use of the IHS resources is a major 
concern. Given our budget constraints, the penalty for not 
effectively managing that demand is going to be falling badly behind 
in terms of processing, storage, and applications development. 


The provision of IHS resources in the Agency has been based on a 
- top-management review and budgeting process. The guiding philosophy 
for this process is understood to have been the provision of whatever 
is needed to get the job done. A primary objective has been 
identified as "encouraging innovation" and the use of "computer 
resources, aS opposed to human resources, by making them free" to the 


user. 


I believe we have passed through the era where we need to 
encourage the use of IHSs and are now approaching one in which the 
emphasis should fall on managing it for efficient utilization. We 
have a limited amount of time to prepare for a certainly predictable 
future. If we do not use this time effectively to develop needed 
procedures and implement functionalities, then we are going to find 
ourselves "behind the power curve." It is a very difficult position 
from which to extract an organization in an environment of rapidly. 
advancing demand and technology. : . : 


ae 
There are two areas of IHS use that, I believe,: need attention: 
on-line data storage and processing. (There are also problems in this 
context relevant to applications development of which the need for 
"user friendly systems" was discussed.) 


While the current information/data generation rate is high, it is 
going to increase substantially. The exploitation processes 
associated with overhead collection systems are generating data at an 
astonishing rate and are due to increase by a factor of maybe four in > 
just a few years. There is also the steadily increasing influx of © 


cable traffic from a variety of sources for analysis by intelligence 
analysts. In addition we are acquiring powerful word processing 
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‘equipment to be broadly distributed throughout the Agency and operate 
off the central systems. This type of equipment approximately doubles 
‘the productivity of a typical staff. 


All of these sources produce data that is being retained on disk 
for real time retrieval. The Ruffing Center disk farm, for example, 
now almost totally fills its allocated first floor space and is still 
‘growing. A large part of this data could be eliminated by tape 
-Storage, archival, and purging. There usually is no justification for 
keeping special applications programs, data or allocated space on-line 
when there has been no activity regarding it for months. Much of the 
data, particularly. that generated in the WP context, is simply the 
detritus ‘of the desty work of the Agency's professionals and should be 
disposed of. = let 


The other efficiency issue is the use of our processing resources. 
There: (are several key dimensions to this concern. We need to: 


o) Establish an effective priority system that enduces 
users with lower priority processing to accept longer job 
turnarounds, offloading peak hours. 


; o Focus on using the most efficient program that will 
meet the needs of the instant problem, and the latest most 
efficient analytic technology in developing analytic tools. 


‘o Provide motivation for the management of operational 
systems to invest more of their enhancement resources in 
‘improving the applications system efficiency. 


Our processing resources are sized very much like electrical power 
generation systems--offloading the peak hours reduces that 
requirement. We need to motivate users in Similar manner to use off- 
prime time hours. For example, can an interoffice message 
appropriately be processed in batch at night for delivery the next 
day, or must it go to the addressees immediately; can a sequence of 
fourier analyses of missile data be packaged for a night time batch 
run, or must they be done one at a time in prime time as they are 
analyzed? 


In developing on-line systems, the primary emphasis is on meeting 
the functional specifications instead of efficiency. After they 
become operational, however, the enhancement process begins. [In 
environments where there are dedicated resources supporting the system 
and they are saturated, there is no shortage of motivation for 
efficiency. Users annoyed by slow system response provide plenty of 
it. In shared processing resource environments, however, motivation 
is needed. Otherwise the user is naturally inclined to want all the 
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enhancement resources to be invested in new functionalities. 


Hardware technology continues to advance rapidly in the data 
processing environment. More powerful processors and higher density 
on-line storage devices are continuously being offered, and assuredly 
we will continue to take advantage of them. We are talking, however, 
about going from 300 to 3000 on-line users in three years. That is an 
explosion of demand that I do not believe technological replacement 
alone é¢dh keep up with. It is certainly the history of the data 
processing industry that users develop new applications at a pace that 
outstrips technology. I see no basis for assuming that will change; 
aie thee our planned explosion in demand will only exaccerbate Lt. 


‘overall, ‘there do not appeat to be adequate forcing functions or 
motivators to control the distribution of data, limit its retention, 
use processing resources in the most efficient manner, and develop 
efficient applications packages. We rely on a few administrative 
procedurés and ad hoc reviews by ODP. We also have our data disposal 
problem compounded by the archaic regulations of the National Archives 
Record Service (NARS). While we need to refine our administrative 
controls aid get relief from the archaic NARS regulations which deal 
in "records" and not "data," neither is likely to be adequate to deal 
with the problem. We need a coordinated and centralized approach to 
efficient use of IHS resources. Better control functionalities 
resident in the central system, and greater motivation for the users 
to use the resources efficiently are needed. 


It takes time and priority sponsorship to develop the needed 
system utilization control tools. Relief from the archaic NARS 
regulations I believe requires that we take a constructive approach 
and define regulations that we believe will work and make sense in our 
environment. If our data control environment has not changed 
substantially two years from now, I believe we will find our ability 
to advance our IHS capabilities absorbed by wasteful and non--~- -- 
productive service and administrator requirements, | ; 
RECOMMENDED ACTIONS CONCERNING THE IHSA \) 


My specific recommendations in approximate order are as follows. 


4. %QIHSA Accredit System Requirements and Approve Systems at Major 
ilestone Reviews 


To define a managerially practical environment, it is recommended 
that there be three categories of systems: Class I (large), Class II 
(medium), and Class III (small). The two thresholds defining the 
boundaries are acquisition cost values. It is recommended that the 
top-management responsibility for the smaller two be delegated to the 
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Directorates, and that the Directorates delegate that for the smallest 
to the constituent Offices. An exception to all such delegations is 
systems with multiple user components, viewed from the next higher 
level, 


The recommended top-management review process consists of three 
milestones: the planning milestone, which is a budgetary milestone 
and which should interface with periodic budgetary processes; the 
system specification milestone, which is a management milestone; and 
the preliminary design review milestone, which is a management 
milestone. The scheduling of the last two are determined by the 
characteristics of the project, and are not synchronized with any 
periodic process. This basic management review process would apply to 
all three categories of systems, and there should be documentation 
requirements for each milestone. Review of the conformance of 
developments with documentation requirements for delegated 
responsibilities would be done by the Inspector General's office as 
part oe their regular periodic manggenen’ audit of offices. 


A format 22% such a top-management process for managing the 
development of systems is attached as Appendix A. This format was 
prepared because it became clear that it was important to clarify the 
mechanism of the intended approval authority for the EXCOM to be able 
to make a knowledgeable judgment. 


It is recommended that the IHSA be authorized to develop a DCI 
Directive concerning accreditation of requirements and approval of 
systems based on this format as it may be modified by the EXCOM. 


It is recommended that the system approval responsibilities 
currently assigned to ODP be assigned to the IHSA, per the approved 
format, in the update of [_] and a new HR defining the 
responsibilities of the IHSA. In this context it is the intent_of the 
IHSA to delegate responsibility to ODP for review of all ADPE embedded 
in new systems for compliance with FIPS, and conformity with our % 
central environment where appropriate. ADPE not embedded in new 
systems would remain the direct responsibility of ODP. The interest 
of this structure is to assure that developers of new systems have 
only one review point, and that the review that is provided is as 
thorough as is the current process. oe Use 


Be IHSA Prepare and Promulgate Agency-wide Procedures and Standards 


Pursuant to the IHSA responsibilities under[ si ODP has 25X1 
passed responsibility for the Agency Standards Committee to this 
office. It is recommended that the IHSA's chairmanship of this 
committee and responsibility for promulgating the Agency's procedures 
and standards,. Suppor ted by this committee, be affirmed. 
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3. TIHSA Plan and Guide IHS Training 


It is recommended that the IHSA provide the top-management 
guidance and support needed to establish a centralized IHSs training 
program. This program would focus on non-component-unique IHS 
training and be implemented within OT&E. 


The process should proceed along three paths simultaneously: 
there should be a follow-on to the training requirements study 
(Appendix B) with all of the Directorates tasked to work with OT&E in 
developing a comprehensive and specific statement of IHS training 
requirements for the fiscal year 1982 through 1985; OT&E should 
evaluate the implications to the organization staffing and regular 
requirements of the Information Science Center of the cost of 
centralized training requirements identified in Appendix B; and 
contractor provided training should be procured by OT&E to respond to 
the immediate training needs of the Agency. A hold should be put on 
the expansion of component IHS training and by both indigenous and 
contractor personnel until the definitive study is complete and 
decisions made. The IHSA will guide the two study efforts and the 
contractor-based quick-response training. 


4. IHSA Guide Resource Allocations with Respect to Long Range 
Architectural Investment Planning 


It is recommended that the IHSA have authority to task various 
Agency offices responsible for the provision of IHS services to 
perform studies of system architecture alternatives relevant to their 
systems. .The studies would be designed to support both the strategic 
planning responsibilities of the INSA and more immediate concerns 
relevant to robustness and provisions of “user friendly" systems. 


The objective of these evaluations will be to achieve through as 
an adjacent of new investments, rather than to restructure the 
existing system--in other words, to take the more economical approach 
of "working our way out." On the basis of the studies,.the THSA 
should review the office resource allocations, and adjust priorities, 
where appropriate, to begin achieving robustness and “user friendly" 
system objectives. 


5. IHSA Guide and Direct the Establishment of a Scientific 
Programming Capability 


It is recommended that a scientific programming capability he 
established within ODP to support scientific programming requirements, 
Agency-wide. The group would be relatively senior, compared to the 
data processing applications development staff. Initially the graup 
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would have twenty mathematical programmer slots, the majority drawn 
from ODP's 1983 programmer increase of 35. 


The IHSA should be tasked to direct a joint study with NFAC and 
ODP to determine the organization, placement and method of operation 
of this group. The objective of the study is to determine the best 
way.to provide thrust of an environment needed to make an Agency 
Career attractive to such personnel, while meeting the operational 
requirements of NFAC and the management requirements of ODP. The 
study report will be made to the EXCOM. 
6. ‘IHSA Chair a Committee to Examine Methods for Improvin 


et is recommended that the IHSA be tasked to develop a set of 
recommended techniques for controlling the efficiency of utilization 
of IHS services. It is recommended that a committee with Agency-wide 
representation be appointed to advise the IHSA in the development of 
this package. To be specifically included are user monitoring 
systems, developing an Agency proposal for a revised NARS regulation 
governing records disposal, and chargeback. A report will be made to 
the EXCOM of the evaluations made and recommended actions. 


7, Publication of a Revised Headquarters Notice Signed b 
he De 


Tt is recommended that a revised Headquarters Notice be prepared © 
and promulgated, pursuant to the findings and direction of this EXCOM. 
In order to avoid lengthy staffing delays, it is recommended that that 
notice be part of the findings documentation. ILLEGIB 
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APPENDIX A 


Policy and Procedures for Management for Information Systems 


A. 


| PURPOSE 


This document is to set forth Agency policy regarding 
management responsibilities for the acquisition of new or 


enhanced Information System capabilities. 


Th oe 
ope 


APPLICABILITY AND SCOPE 


The provisions of this document apply to automated or other 
clearly identifiable processes used for creation, movement, 
use, storage, retrieval, or dissemination of intelligence and 
management information. Included are ADP hardware and 
software systems, communications sytems, terminals, word- 
processing, printers and copiers, image processing and 


display, and collection systems. 


POLICY 


i. General 


Information System acquisitions shall be reviewed and 
approved at decision milestones by appropriate management 
levels. Systems of extraordinary cost, risk, or interest 
shall be reviewed by the EXCOM; the Information Handling 
Systems Architect (IHSA) and the Program Management iedaaei” Lys 
Component shall support the EXCOM review process. 
Information Systems falling below the EXCOM ‘review 
threshold, but nevertheless important: in the ‘context of 
Agency Information Systems Architecture and Planning, may 
be reviewed by the IHSA at decision milestones. 


2. Specific | san Aches «25h 


For purposes of management and coordination there are 
three classes of information systems, determined by 
investment cost thresholds. Class I and II systems shall 
comply with the procedures, standards, and documentation 
requirements for major programs. Class III programs 
shall comply with the procedures, standards and 
documentation requirements for minor programs. 
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a) Class I Informations Systems shall be reviewed and 
approved at decision milestones by the EXCOM. Any 
Information System, or any significant revision of an 
‘existing Information System, meeting any one of the 
following criteria shall be designated a Class I 
Information System: . 


i) Has anticipated acquisition costs in excess of 
$8 million during the span from program 
initiation to the time the system becomes 
operational; or 


ii) Has estimated costs in excess of $2 million in 
- any year; or 


4ii) Is designated as being of special interest. 


iv) Information Systems which do not meet the 

criteria for Class I Information System 
designation, but which are considered to have 
Agency-wide or community importance shall be 
reviewed and approved by the IHSA. In 
particular, a number of information systems of 
similar character, but less than Class I 
threshold, may be aggregated and considered as 
a Class I system. Review procedures used for 
such Class I systems will be tailored as 
appropriate by the IHSA. 


b) Class II Information Systems shall be reviewed and 
approved at decision milestones by the Deputy 
Director responsible for the system. Any Information 
System, or any significant revision of an existing | 
Information System, meeting any of the following 
criteria shall be designated a Class II Information 
System: = . 

i) Has anticipated acquisition costs in excess of 
$1 million during the year from program 
initiation to the time the system becomes 
operational; or 


ii) Has estimated acquisition costs in excess of 
$250,000 in any year; or 


iii) Is designated as being of special interest. 


c) Class III Information Systems shall be reviewed and 
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approved as the responsible Deputy Director may 
direct. In general, it is anticipated that he will 
delegate that authority to the next lower level of 
management. Any information system, or any 
significant revision of an information system which 
is in cost or importance less than Class If is a 
Class III system. 


For the purpose of estimating acquisition costs the 
value of one person-year of professional effort will 
be $100,000 regardless of the sources. 


Milestone Decisions 


Three milestone decisions are defined for acquisition of 
Major Information Systems. 


o Milestone 0 Decision -- Approval of Mission Need 


Statement approval of the budget and schedule, 
and authorization to proceed to the next program 
phase. The Mission Need Statement shall define. 
the need for the system, and shall be 
accompanied by Preliminary System Requirements, 
acquisition strategy, schedule goals, and the 
total and annual investment of resources 
estimated. The next program phase for a simple 
package (no program development investment, 
e.g., a computer with standard support software) 
is the actual procurement, or for a complex 
system development. The next phase is the 
Concept Development Phase. 


Milestone 1 Decision -- Approval of the System ~. 


Design Concept, System Requirements, and Program 
Development Plan; and authorization to proceed 
with the next program phase. For’ large complex 
systems, alternate concepts are to be explored 
and evaluated before settling on a chosen 
concept, the reasons for a particular selection 
are to be presented. Documentation at this 
stage shall include baseline System 
Requirements, System Design Concept, and a 
Program Development Plan. System requirements 
will be accredited by the IHSA. Cost and 
schedule goals are reassessed. Equipment plans 
are presented for approval, and acquisition of 
fully designed, commercial hardware will 
normally be executed pursuant to this approval 
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or direction. Approved programs then proceed to 
the Preliminary Design Phase. 


o Milestone 2 Decision -- Approval of the 
Preliminary Design and Revised Program 
Development. All acquisition programs, however 
phased, will have a single Preliminary Design 
Review (PDR) covering the entire program. This 
review is coordinated with the program’ s 
internal PDR so that issues arising as a panne 
of the PDR process can be evaluated. At this 
milestone review the program cost, 
functionality, and schedule objectives, 
primarily as defined and determined at the PDR, 
are reassessed. Approved programs then proceed 
to full- reer development. 


At each secieeen milestone, guidance and direction to 
the program are documented, 


At any point at which a program deviation in cost or 
schedule goals of more than 15 percent is estimated, 
the IHSA will be notified. He may, at his discretion 
convene an ad hoc review of the project status. 


Procedures 


At least six months prior to Milestone 1 or 2 review of 
Class I and II systems the program sponsor will notify 
the IHSA. For Class I systems, the IHSA will coordinate 
and schedule an EXCOM review. 


The IHSA will appoint a member of his staff to 
coordinate with the program office concerning 
preparation for the Milestone review. The program 
office will brief the IHSA office with respect to the 
program status for Class I and II systems. ‘ Questions 
which the office of the IHSA has with the project will 
be addressed to the project management. The intent is 
to resolve all the questions that pertain to such 
matters as the project formulation, completeness of 
planning and design, interoperability, conformity with 
standards, and supportability prior to the Milestone 
review. 


Tene anette 


Shortly prior to the review, the IHSA will prepare brief 
point papers covering any points of concérn or 
disagreement relative to the information system's 
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development. Approximately one week prior to the EXCOM 
Milestone review of Class I systems, the IHSA will 
prebrief the EXCOM concerning unresolved issues and 
concerns. The project management will then brief the 
EXCOM on the system at the Milestone review. The IHSA 
will then prepare a decision coordinating paper 
documenting the EXCOM guidance and direction to the 
project. 


Por Class II systems, if the IHSA feels that there are 
significant architectural concerns, he may join the 
Milestone review. If those concerns still remain 
following the review, the IHSA may schedule an EXCOM 


review. 


THSA Responsibilities 

The Information System review process is the management 
compliment to the budgeting process. Information System 
decisions must fit into the affordability framework of 
the budget, and further, must fit into the Agency 
architecture and planning framework for Information 
Systems. In that context specific IHSA responsibilities 
include: 


a) Formulating overall architecture tenets for 
Information Systems — 


b) Conducting formal reviews of proposed 
Information Systems to: 


o Accredit requirements 


o Determine compliance with architecture -~—.... 
tenets s 


o Validate Functional Ae Gui Sinan S 
o Validate System Concept . ‘ 


o Ensure that relevant interfaces are 
considered 


o Validate information security of proposed 
design 


c) Advising on relative priorities of Information 
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Systems 
d) Focusing the issues for EXCOM reviews 


e) Making an annual report to the EXCOM on the 
status of IHSs in the Agency and advising EXCOM 
on Information Systems decisions 


f) Designated individual for the Agency assuring 
compliance with government-wide standards and 
procedures. Included is assuring Agency 
compliance with Federdl Information Processing 
Standards, or: granting waivers these to in 

accordance with delegated authorities and 
‘specified procedures. 


ILLEGIB 
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